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AIRCRAFT  TRAJECTORY  MODELING  AND  ALERTING  ALGORITHM 

VERIFICATION* 


CESAR  MUNOZ*  AND  VICTOR  CARRENO* 

Abstract.  The  Airborne  Information  for  Lateral  Spacing  (AILS)  program  at  NASA  Langley  Research 
Center  aims  at  giving  pilots  the  information  necessary  to  make  independent  approaches  to  parallel  runways 
with  spacing  down  to  2500  feet  in  Instrument  Meteorological  Conditions.  The  AILS  concept  consists  of 
accurate  traffic  information  visible  at  the  navigation  display  and  an  alerting  algorithm  which  warns  the 
crew  when  one  of  the  aircraft  involved  in  a  parallel  landing  is  diverting  from  the  intended  flight  path.  In 
this  paper  we  present  a  model  of  aircraft  approaches  to  parallel  runways.  Based  on  this  model,  we  analyze 
the  alerting  algorithm  with  the  objective  of  verifying  its  correctness.  The  formalization  is  conducted  in  the 
general  verification  system  PVS. 

Key  words,  trajectory  modeling,  alerting  algorithm,  formal  methods,  theorem  proving 

Subject  classification.  Computer  Science 

1.  Introduction.  The  Airborne  Information  for  Lateral  Spacing  (AILS)  [12,  3,  6]  is  a  project  being 
conducted  at  NASA  Langley  Research  Center.  Its  objective  is  to  reduce  traffic  delays  and  increase  airport 
efficiency  by  enabling  approaches  to  closely  spaced  parallel  runways  in  Instrument  Meteorological  Conditions. 

Approaches  to  parallel  runways  are  currently  limited  to  4300  feet  in  Instrument  Meteorological  Condi¬ 
tions.  Specially  equipped  airports  with  fast  scan  radars,  high  resolution  monitoring  systems,  and  approach- 
specific  air  traffic  controllers  can  perform  parallel  approaches  to  3400  feet  [14,  8].  The  AILS  project  aims  at 
shifting  the  responsibility  of  maintaining  separation  during  parallel  approaches  from  the  air  traffic  controller 
to  the  aircraft  crew.  Via  the  AILS  concept,  approaches  to  parallel  runways  2500  feet  apart  in  Instrument 
Meteorological  Conditions  are  expected. 

AILS  eliminates  the  delay  inherent  in  the  communication  between  air  traffic  controller  and  crew  by 
displaying  parallel  traffic  information  in  the  cockpit.  The  degree  of  safety  is  enhanced  by  an  alerting  system 
which  warns  the  crew  when  one  of  the  aircraft  involved  in  a  parallel  landing  is  deviating  from  the  intended 
flight  path.  The  alerting  algorithm  is  a  critical  part  of  the  AILS  concept.  Flaws  in  its  logic  could  lead  to 
non- alerted  collision  incidents.  The  algorithm  has  been  extensively  tested  in  simulators  and  in  real  flights. 

The  objective  of  this  work  is  to  conduct  a  formal  analysis  of  the  alerting  algorithm  in  order  to  discover 
any  possible  errors  that  have  not  been  detected  during  testing  and  simulation.  In  particular,  we  develop  a 
formal  model  of  parallel  landing  scenarios.  Based  on  this  model,  we  study  the  behavior  of  the  AILS  algorithm 
with  respect  to  predictions  of  collision  incidents. 

The  formalization  presented  in  this  paper  has  been  developed  in  the  general  verification  system  PVS 
[11].  We  use  a  stylized-IAI^K  PVS  concrete  syntax  and  assume  the  reader  is  familiar  with  standard  notations 
of  higher- order  logic. 

*This  work  was  supported  by  the  National  Aeronautics  and  Space  Administration  under  NASA  Contract  No.  NAS  1-97046 
while  the  first  author  was  in  residence  at  the  Institute  for  Computer  Applications  in  Science  and  Engineering  (ICASE),  NASA 
Langley  Research  Center,  Hampton,  VA  23681-2199,  USA. 

^Institute  for  Computer  Applications  in  Science  and  Engineering  (ICASE),  Mail  Stop  132C,  NASA  Langley  Research  Center, 
Hampton,  VA  23681-2199,  USA,  e-mail:  munoz@icase.edu. 

t Assessment  Technology  Branch,  Mail  Stop  130,  NASA  Langley  Research  Center,  Hampton,  VA  23681-2199,  USA,  e-mail: 
v.a.carreno@larc.nasa.gov. 
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Table  2.1 
Alerting  sequence 


Evader 

Intruder 

1 

Localizer  alert  (one  dot  deviation) 

2 

Localizer  alert  (two  dot  deviation) 

B 

Caution  alert  (traffic) 

4 

Caution  alert  (traffic) 

5 

Warning  alert  (collision) 

6 

Warning  alert  (collision) 

The  remainder  of  this  paper  is  organized  as  follows.  Section  2  gives  an  overview  of  the  AILS  system. 
Section  3  describes  the  alerting  algorithm  and  its  abstraction  in  PVS.  A  formal  model  of  aircraft  trajectories 
is  presented  in  Section  4.  Section  5  contains  the  main  properties  that  have  been  proven  in  PVS.  Section  6 
summarizes  our  work  and  suggests  future  research  directions.  Finally,  the  appendix  includes  our  PVS  formal 
model  which  is  electronically  available  at:  http://shemesh.larc.nasa.gov/people/vac/ails.pvs. 

2.  System  Description.  In  a  typical  independent  parallel  approach,  aircraft  intersect  their  localizer 
track  (longitudinal  runway  center)  approximately  10  nautical  miles  from  the  runway  threshold  (see  Fig¬ 
ure  2.1).  During  localizer  intersection,  aircraft  have  a  1000  feet  vertical  separation.  After  the  aircraft  are 
established  in  their  localizer  track,  vertical  separation  is  eliminated  and  aircraft  start  a  normal  glide  path  for 
landing.  If  an  aircraft  deviates  from  its  airspace,  the  AILS  system  provides  6  alert  levels,  depending  on  the 
severity  of  the  deviation.  Table  2.1  shows  an  alerting  sequence  as  seen  in  the  evader  and  intruder  aircraft 
primary  and  navigation  displays. 

All  alerts  in  the  intruder  aircraft  are  expected  to  be  followed  by  a  corrective  maneuver.  The  evader 
aircraft  is  not  expected  to  perform  an  evasive  maneuver  until  a  warning  alert  is  issued,  at  which  time  landing 
is  aborted  and  an  emergency  escape  maneuver  is  performed.  Notice  that  the  intruder  aircraft  always  receives 
a  caution  or  warning  alert  before  the  respective  caution  or  warning  alerts  are  issued  to  the  evader.  A  parallel 
runway  approach  is  illustrated  in  Figure  2.1. 

Several  assumptions  were  made  in  the  development  of  the  alerting  algorithm.  These  assumptions  are 
justified  by  physical  characteristics  and  operational  constraints.  They  are  as  follows: 

•  Time  is  discrete  and  divided  in  increments  of  0.5  seconds.  We  call  this  value  tstep. 

•  The  algorithm  is  executed  every  tstep  seconds. 

•  The  rate  of  turn  is  determined  by  the  bank  angle  and  ground  speed. 

•  The  speeds  of  the  aircraft  are  constant.  Henceforth,  we  use  intruder  Speed  and  evader  Speed  as 
the  constant  speed  values  of  the  intruder  and  evader  aircraft,  respectively. 

•  The  AILS  system  starts  operating  when  the  aircraft  are  on  their  localizers.  At  this  time  the  aircraft 
are  approximately  at  the  same  altitude. 

•  The  vertical  separation  between  the  aircraft  is  assumed  to  be  0  during  a  landing  approach. 

•  Only  the  intruder  aircraft  will  deviate  from  its  path  in  a  parallel  approach.  The  evader  aircraft  stays 
in  its  localizer. 

It  should  be  noted  that  the  experimental  AILS  system,  as  currently  designed,  forms  part  of  the  Traffic 
Alert  and  Collision  Avoidance  System  (TCAS)  [13].  In  this  work,  we  assume  that  the  AILS  alerting  algorithm 
is  running  in  isolation  from  other  aircraft  components.  In  addition,  we  concentrate  on  the  caution  and 


2 


X 


h 


10  NM 


Two  Dot  Deviation 
One  Dot  Deviation 
Localizer  Track 


Fig.  2.1.  Parallel  runway  approach 


warning  alerting  kernel  of  the  AILS  alerting  system.  The  one  dot  and  two  dot  deviation  alerts  present  a 
simple  scenario  and  can  be  easily  added  to  our  model  by  a  separate  function  as  it  is  done  in  the  current 
implementation. 

3.  The  AILS  Alerting  Algorithm.  The  alerting  algorithm  determines  when  an  alarm  will  be  trig¬ 
gered  by  calculating  possible  collision  trajectories  and  comparing  the  future  aircraft  locations  with  predeter¬ 
mined  time  and  distance  thresholds.  The  algorithm  is  executed  in  two  modes  every  tstep  seconds:  (1)  the 
first  mode  assumes  its  own  aircraft  is  a  threat  to  the  adjacent  aircraft  and  the  adjacent  aircraft  is  following 
the  localizer;  (2)  the  second  mode  assumes  the  adjacent  aircraft  is  a  threat  to  its  own  and  the  own  is  following 
the  localizer.  In  either  mode,  one  aircraft  is  the  intruder  and  one  is  the  evader. 

When  the  intruder  aircraft  is  not  changing  direction,  i.e.,  its  bank  angle  is  0,  the  algorithm  determines 
if  the  two  aircraft  are  diverging  or  converging  and  the  point  of  closest  separation.  This  is  done  by  obtaining 
the  derivative  of  the  distance  between  the  aircraft  and  solving  for  time  when  the  derivative  equals  zero  as 
follows. 


(3.1) 

(3.2) 

(3.3) 

(3.4) 

(3.5) 

(3.6) 


A x(t)  =  Xin(t)  -  Xev(t) 
A y(t)  =  Vin(t)  -  yCv{t) 


-—Ax(t)  =  intruderSpeed  x  cos(9)  -  evaderSpeed 
at 


—  A y(t)  =  intruderSpeed  x  sin{6) 
at 


R(t)  =  A.T(t)2  +  A„(i)2 

d  r>/iN  _  A x{t)  X  +  A y(t)  x  ^A y(t) 

=R<  ’  ■  7m 


For  a  time  £,  {xin(t),yin(t))  and  ( xev(t),yev(t ))  are  the  coordinates  of  the  intruder  and  evader  aircraft, 
respectively,  and  0  is  the  heading  angle  of  the  intruder  aircraft.  When  +  r)  =0,  we  get  the  time  r, 

relative  to  £,  of  the  point  of  closest  separation  of  the  aircraft.  Time  r  has  been  calculated  as 


(3.7) 


r{t)  = 


Ax(()  X  ■jftAxff)  -t-  Ay(t)  X  ^Ay{t) 
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Fig.  3.1.  Converging  tracks 


Fig.  3.2.  Radial  trajectory  and  tangential  tracks 


Equations  3.1  to  3.7  were  formally  deduced,  from  initial  physical  properties,  by  using  the  computer 
algebra  tool  MuPAD  [4].  Notice  that  r  is  undetermined  when  the  aircraft  are  parallel  and  the  ground  speeds 
are  equal.  In  this  case,  the  alerting  algorithm  defines  r(t)  =  0  for  any  t. 

For  a  time  if  r(t)  is  negative  or  zero,  the  tracks  are  diverging  or  parallel,  respectively.  If  r(t)  is  greater 
than  zero,  the  tracks  are  converging  and  r(t)  will  be  the  time  of  closest  separation  (Figure  3.1).  When  tracks 
are  diverging  or  parallel,  the  algorithm  checks  the  aircraft  separation  at  the  present  time  against  the  alert 
threshold  distances  (cdist  and  wdist  in  Figure  2.1).  When  tracks  are  converging,  the  algorithm  compares 
the  time  and  distance  of  closest  separation  against  time  and  distance  thresholds,  respectively. 

When  the  intruder  aircraft  is  changing  direction,  i.e.,  its  bank  angle  is  not  0,  the  algorithm  calculates 
the  radius  of  the  turn  and  the  rate  of  change  of  direction.  Tangential  tracks  are  calculated  from  the  arc  path 
as  to  produce  tangents  which  arc  1.5°  to  3°  in  angular  separation  (Figure  3.2).  For  each  of  these  tangential 
tracks  the  algorithm  determines  whether  the  two  aircraft  tracks  are  diverging  or  converging  and  performs 
time  and  distance  comparisons  as  explained  above. 

The  original  AILS  algorithm  was  written  in  FORTRAN  at  Langley  Research  Center,  It  has  been  revised 
several  times  and  the  latest  version  flown  in  the  Boeing  757  experimental  aircraft  was  provided  by  Honeywell. 

For  the  work  presented  in  this  paper,  we  created  a  high  level  abstract  model  of  the  alerting  algorithm  in 
the  PVS  language.  The  algorithm  model  uses  the  same  strategy  as  the  FORTRAN  algorithm  to  determine 
if  alarms  are  triggered,  as  explained  above.  All  of  the  PVS  declarations  involved  in  the  modeling  of  the 
algorithm  can  be  seen  in  the  theory  file  available  at  http://shemesh.larc.nasa.gov/people/vac/ails. 
pvs. 

The  model  of  the  algorithm  is  a  function  which  takes  the  states  of  the  aircraft  and  returns  a  boolean 
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value  corresponding  to  whether  the  alarm  is  triggered  or  not.  The  type  of  the  alarm,  caution  or  warning, 
depends  on  the  threshold  parameters.  The  state  of  the  aircraft  is  defined  by  a  record: 


state  :  TYPE  = 
[#  x 

y 

heading 

phi 


real , 
real, 

[-180. . .180] 
[-45. . .45] 


We  recall  that  access  to  records  are  written  in  PVS  as  function  calls,  i.e.,  if  s  is  a  state,  x(s)  refers 
to  the  field  x  of  the  state  s.  Thus,  x(s)  and  y(s)  are  the  position  coordinates,  heading (s)  is  the  angle 
between  the  flight  path  and  the  localizer  track  which  range  between  —180°  and  180°,  and  phi(s)  is  the 
aircraft  bank  angle  between  —45°  and  45°. 

The  model  of  the  alerting  algorithm  is  given  next. 


larcalert (evader, intruder: state) :  bool  - 
LET  phi  =  phi (intruder)  IN 

LET  trkrate  =  gx  (180/7r)  xtand(phi)/intruderSpeed  IN 


'/,  Direction  is  not  changing. 
’/,  Check  strait  tracks . 

'/,  Direction  is  changing 
V.  Calculate  arc  radius. 


IF  trkrate  =  0  THEN 
chktrack(O) 

ELSE 

LET  arcrad  - 

intruderSpeed2/(pXtand(phi) )  IN 
LET  maxstep  =  alert _time/tstep  IN 
LET  idtrk  = 

IF  abs (trkrate)  >  3- THEN  1 
ELSIF  abs (trkrate)  >  1+1/2  THEN  2 
ELSIF  abs  (trkrate)  >  3/4  THEN  4 
ELSE  8 
END IF  IN 

arc_loop (evader , intruder , arcrad , trkrate , idtrk, 0 , maxstep) 
END  IF 


'/,  This  determines 
X  how  often 
%  tangential 
'/,  tracks  are 
*/,  calculated. 


where  g  is  the  gravitational  acceleration  constant  (approx.  32.2  feet/seconds2). 

The  first  part  of  the  function  is  exercised  when  the  track  rate  (trkrate)  is  zero  and  there  is  no  change 
in  the  intruder’s  heading.  The  chktrack  function  is  used  to  determine  if  an  alarm  will  be  triggered.  The 
function  chktrack  makes  the  calculation  for  converging  or  diverging  tracks,  according  to  Equations  3.1 
to  3.7.  If  the  tracks  are  diverging,  the  function  chkrange  is  called  to  compare  present  locations  against  time 
and  distance  threshold  (ctime  and  cdist,  respectively).  If  the  tracks  are  converging,  predicted  locations  at 
caution  time  or  time  of  closest  separation,  whatever  is  smaller,  are  compared.  The  structure  of  the  definitions 
of  chkrange  and  chktrack  are  given  next. 


chkrange (range, t : real) :  bool  = 
range  <  cdist  A  t  <  ctime 

chktrack (t : real) :  bool  = 

LET  range  =  R( t)  IN 
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LET  tan  =  r(t)  IN 
IF  tau  <  0  THEN 
chkrange (range , t) 

ELSE 

IF  t+tau  >  ctime  THEN 
i?(c time)  <  cdist 
ELSE 

R( t+tan)  <  cdist 
ENDIF 
END  IF 


'/,  Tracks  are  diverging  (or  parallel)  . 

'/,  Check  range  at  prediction  time  t. 

I  Tracks  are  converging. 

'/,  Closest  separation  beyond  caution  alert  time. 
I  Check  range  at  caution  threshold. 

I  Closest  separation  within  caution  alert  time. 
I  Check  range  at  time  of  closest  separation. 


The  second  part  of  the  function  larcalert  handles  the  case  when  intruder  is  changing  direction.  The  arc 
radius  is  calculated  and  the  function  arc_loop  generates  the  tangential  tracks  from  the  arc  trajectory.  The 
function  arc.loop  is  a  recursive  function  modeling  a  DO-LOOP  statement.  It  is  used  to  iterate  the  function 
chktrack  on  tangential  tracks  every  idtrk  time  steps.  Its  actual  definition  is  too  long  to  be  included  in  the 
paper  and  can  also  be  seen  in  the  theory  file  as  pointed  above.  The  structure  of  the  function  is: 


arc_loop (evader , intruder , arcr ad ,trkrate , idtrk, iarc ,maxstep) : 
calculate  positions  of  aircraft 
IF  not  time  for  a  tangential  track  THEN 


IF  chkrange (...)  THEN 
TRUE 
ELSE 

arc_loop( . . . ) 

ENDIF 

ELSE 

IF  chktrk( . . . )  THEN 
TRUE 
ELSE 

arc_loop( . . . ) 

ENDIF 

ENDIF 


*/,  Check  range  at  that  point, 
y.  Trigger  an  alarm. 

I  Go  to  new  iteration. 

i  Time  for  tangential  tracks. 
I  Check  track  at  this  point. 

*/,  Trigger  an  alarm. 

*/,  Go  to  new  iteration. 


RECURSIVE  bool  = 


Based  on  the  idtrk  argument  and  the  step  in  the  loop  iarc,  the  function  arc_loop  determines  if  a 
tangential  track  is  calculated  or  not.  If  a  tangential  track  is  not  calculated,  the  function  chkrange  compares 
the  distance  between  the  calculated  positions  of  the  aircraft  and  the  distance  threshold.  The  function  chktrk 
is  used  to  check  for  collisions  on  all  the  tangential  tracks  in  the  loop.  The  function  arcJLoop  terminates 
when  one  of  the  functions  chkrange  or  chktrack  triggers  an  alarm  or  when  iarc  has  reached  maxstep. 

In  the  PVS  model,  we  are  using  an  axiomatic  definition  of  the  square  root  function  (sqrt,  see  Section 
5).  Trigonometric  functions  (sind,  cosd,  and  tand,  for  sine,  cosine,  and  tangent  of  angles  in  degrees, 
respectively)  are  defined  by  series  approximations.  However,  as  we  will  see  in  Section  5,  we  also  provide 
axioms  about  trigonometric  functions  to  facilitate  the  proofs. 

As  we  have  seen,  the  AILS  algorithm  considers  a  limited  set  of  possible  trajectories  for  the  intruder 
aircraft,  i.e.,  assuming  a  constant  radius  turn  at  the  original  bank  angle,  only  tangent  track  escapes  to  the 
turn  arc  are  considered.  The  developers  of  the  algorithm  state  that  this  assumption  is  reasonable  under 
normal  circumstances,  i.e.,  the  intruder  aircraft  is  not  intentionally  trying  to  collide  with  the  evader  aircraft. 
However,  to  evaluate  the  behavior  of  the  algorithm  in  a  wider  range  of  possible  landing  scenarios,  a  more 


6 


general  model  of  trajectories  for  the  intruder  aircraft  is  necessary.  In  the  next  section,  we  develop  such  a 
model. 


4.  Parallel  Landing  Scenarios.  According  to  the  characteristics  and  assumptions  of  the  AILS  algo¬ 
rithm,  we  propose  a  time-discrete  model  with  time  increments  of  tstep  seconds. 

In  our  model  of  trajectories,  as  in  the  case  of  the  alerting  algorithm,  intrusion  paths  are  determined  by 
the  bank  angle  and  ground  speed  of  the  intruder  aircraft.  Given  a  ground  speed  gs  >  0,  a  bank  angle  the 
heading  turn  rate  is  given  by 

,  tand(d) )  x  q  x  180 

trkrate(gs,  4>)  =  - — — - , 

gs  X  7T 

where  g  is  the  gravitational  acceleration  constant. 

Although  under  normal  operation  the  bank  angle  of  a  commercial  aircraft  is  limited  to  -30°  to  30°,  we 
allow  the  bank  angle  to  range  from  -45°  to  45°.  For  a  minimum  ground  speed  of  180  feet  per  second,  it 
means  a  maximum  heading  turn  rate  of  about  6°  per  second.  These  data  produce  very  aggressive  blundering 
situations  quite  consistent  with  worst  cases  scenarios  tested  by  the  AILS  developing  group.  Incidentally,  the 
function  trkrate  is  well-defined  for  bank  angles  in  the  range  [—45  . .  .45]. 

Definition  4.1  (Intruder  trajectory).  An  intruder  trajectory  of  length  n  for  an  aircraft  with  state  s 
and  ground  speed  gs  is  a  sequence  of  states  sq  ...  sn  such  that  sq  =  s  and  for  0  <  i  <  n, 

1.  <  45, 

2.  | heading(si)  -  heading(si- 1)|  —  tstep  x  trkrate(gs,  phi(si)), 

3.  x(si)  =  -f  gs  x  tstep  x  cosd(heading(Si))}  and 

4 .  y(s{)  =  y(si-i)  4*  gs  x  tstep  x  sind(heading(si)). 

In  PVS,  we  define  the  next  state  of  an  intruder  aircraft  at  state  s  and  bank  angle  0  by  the  function 

next_intruder_state(s:  state  [-45.  .  .45]  ) :  state  = 

LET  trk  =  heading (s)  +  tstep x trkrate (intruderSpeed, phi (s))  IN 
s  WITH  [ 

x  :=  x(s)  +  intruderSpeedxtstepXcosd(trk)  , 

y  :=  y(s)  +  intruderSpeedXtstepxsind(trk)  , 

heading  :=  trk, 

phi  :  =  (j) 

] 

We  recall  that  WITH  is  the  record  (and  function)  overriding  operator  in  PVS. 

We  model  an  intruder  trajectory  by  a  recursive  function  having  as  parameters  an  initial  state  s,  a  bank 
angle  assignation  for  each  iteration  step  df ,  and  the  iteration  step  n,  as  follows 

intruder_trajectory (s : state ,  df :  [posnat— >  [-45 . . .45]]  ,  n:nat): 

RECURSIVE  state  - 
IF  n  =  0  THEN  s 
ELSE 

LET  sn  ~  next_intruder_state(s ,  df (n) )  IN 
intruder  ..trajectory  (sn,df  ,n-l) 

ENDIF 
MEASURE  n 
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For  example,  given  an  intruder  aircraft  at  initial  state  s  and  bank  angle  equal  to  0,  a  trajectory  of  length 
n  such  that  the  plane  follows  a  straight  line  to  its  current  heading  angle  is  given  by  s0  . . .  sn,  where  so  =  s 
and  for  0  <  i  <  n, 


Si  —  intruder_trajectory(s,  A(n  :  posnat)  :  0,2). 

For  the  evader  aircraft,  we  assume  that  it  stays  in  its  localizer  with  a  constant  speed  and  constant 
heading  of  0°.  Heading  and  bank  angles  are  irrelevant  in  the  definition  of  an  evader  trajectory. 

DEFINITION  4.2  (Evader  trajectory).  An  evader  trajectory  of  length  n  for  an  aircraft  with  state  s  and 
ground  speed  gs  is  a  sequence  of  states  sq  . . .  sn  such  that  so  =  s  and  for  0  <  i  <  n} 

1.  ®(sj)  =  x(si_i)  +  gs  x  tstep  and 
y(-n)  =  y(so)- 

For  an  initial  state  s  of  an  aircraft,  its  state  after  n  steps  in  a  evader  trajectory  is  defined  by  evader  .trajectory  (s  ,n) 
as  follows 

evader_trajectory(s: state,  n:nat):  state  = 

(# 

x  :=  x(s)  +  evaderSpeedXtstepXn, 

y  :=  y(s) , 

heading  :=  heading(s) , 

phi  : =  phi(s) 

#) 

We  are  interested  in  trajectories  leading  to  collision  incidents.  Aircraft  are  said  to  be  in  collision  if  the 
distance  between  them  is  less  than  or  equal  to  collisionRange.  In  our  development,  we  consider  200  feet 
for  collisionRange,  which  is  approximately  the  wing  span  of  a  Boeing  747. 

distance (si , s2 : state) :  real  = 

sqrt( (x(s2)-x(sl)) 2  4*  (y (s2) -y (si) ) 2) 

collision(sl ,s2: state) :  bool  = 
distance (si ,s2)  <  collisionRange 

Definition  4.3  (Collision  scenario).  Given  an  intruder  trajectory  so  . .  .sn  and  an  an  evader  trajectory 
to  . .  .tn,  we  said  that  they  lead  to  a  collision  incident  at  step  i,  for  0  <  i  <  n,  if  collision(sifti)  holds. 

In  PVS, 

collision.scenario (intruder, evader : state,  df : [posnat— >  [-45 . . .45]]  , 
i :nat) :bool  = 

collision(intruder_trajectory (intruder ,df ,i) , 
evader_trajectory (evader ,i) ) 

We  have  implemented  the  model  of  trajectories,  together  with  our  high-level  version  of  the  alerting 
algorithm,  in  Java.  The  implementation,  available  in  the  same  location  as  the  PVS  theory  files,  serves  a 
double  purpose.  First,  it  allows  us  to  visualize  all  the  collision  trajectories  for  a  given  time  and  initial  values 
of  the  intruder  and  evader  aircraft.  Second  and  more  importantly,  by  studying  those  trajectories,  we  were 
able  to  extract  conjectures  that  we  have  then  formally  proven  in  PVS.  Conversely,  as  we  will  mention  later, 
we  have  rejected  some  conjectures  by  finding  counter-examples  via  simulation  of  collision  trajectories, 
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In  the  next  section,  we  address  the  formal  verification  of  properties  of  collision  trajectories  for  our  model 
in  PVS,  and  we  study  the  behavior  of  the  alerting  algorithm  with  respect  to  that  model. 

5.  Main  Properties.  The  objective  of  this  modeling  and  verification  work  is  (i)  to  show  that  the 
method  implemented  in  the  algorithm  to  predict  trajectories  and  trigger  alarms  is  adequate  and  does  not 
lead  to  dangerous  situations,  or  (ii)  to  explore  possible  trajectory  scenarios  which  lead  to  unacceptable  risk. 
To  this  effect  we  created  models  of  the  algorithm  and  aircraft  trajectories  in  PVS,  created  simulations  in 
JAVA  to  visualize  the  behavior  and  characteristics  of  the  landing  scenario,  and  verified  in  the  computer 
algebra  tool  MuPAD  some  axiomatic  definitions  we  made  in  PVS. 

Before  stating  the  main  properties,  it  should  be  said  that  most  of  the  proofs  require  reasoning  on 
continuous  mathematics.  We  have  assumed  some  uninterpreted  functions  and  axioms  in  PVS,  for  instance 

sqrt(x:real)  :  {zrreal  I  z2  =  x  and  z  >  0} 

sin_cos_sq_one  :  AXIOM 

V  (x : real) :  sind(x)2  +  cosd(x)2  =  1 

More  involved  properties,  grounded  on  Equations  3.1  to  3.7,  are  also  necessary,  e.g., 

derivative_eq_zero_min  ;  AXIOM 

V  (tl ,t2 :real) :  jR(tl+r(tl))  <  I?(tl+t2) 

asymptotic_decrease_zero_to_tau  :  AXIOM 

V  (t ,tl ,t2 :real)  : 

r(t)  >  0  A  t2  <  t( t)  A  tl  <  t2 

=>> 

>  jR(t+t2) 

asymptotic_increase_tau_to_zero  :  AXIOM 

V  (t  ,tl ,t2 :real)  : 

r(t)  <  0  A  t2  >  r( t)  A  tl  >  t2 

i?,(t+tl)  >  i?.(t+t2) 

Axiom  derivative_eq_zero_min  states  that  at  time  t,  r(t)  would  be  the  time  of  closest  separation 
between  the  aircraft.  Axioms  asymptotic_decrease_zero_to_tau  and  asymptotic_increase_tau_to_zero 
state  that  function  R  asymptotically  decreases  for  times  less  than  r(t)  and  asymptotically  increases  for 
times  greater  than  r(t),  respectively.  As  we  have  mentioned  before,  the  equations  of  Section  3  have  been 
symbolically  deduced  in  MuPAD. 

Our  intention  is  to  show  that  for  all  aircraft  trajectories  which  lead  to  a  collision  and  all  initial  states1 , 
an  alarm  is  issued  i  seconds  before  a  collision.  In  our  formal  development,  we  have  found  upper  and  lower 
bounds  for  the  values  of  i. 

One  of  the  first  properties  that  we  have  proven  is  that  an  alarm  (caution  or  warning)  is  triggered  when 
the  distance  between  the  aircraft  is  within  the  alerting  range  (cdist  or  wdist,  respectively).  This  property 
holds  independently  of  the  values  of  any  other  state  variables  of  the  aircraft. 


1  Recall  from  Section  2  that  initial  states  are  when  the  aircraft  are  oil  their  localizers. 
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alarm_when_alerting_distance  :  THEOREM 

V  (evader, intruder : state)  : 

alert ing.distance (evader, intruder)  =>  larcalert (evader, intruder) 

The  theorem  above  puts  the  greatest  lower  bound  on  the  elapsed  time  between  an  alert  and  a  collision 
that  we  have  found  so  far.  For  an  alerting  distance  of  1400  feet  and  an  intruder  ground  speed  of  250  feet 
per  second  this  results  in  an  alarm  at  least  4  seconds  before  collision. 

An  effort  to  prove  that  a  caution  is  issued  for  a  value  of  (ctime-1)  (ctime  being  defined  as  19  seconds) 
resulted  in  an  unprovable  conjecture.  Indeed,  we  have  found  a  counter  example  of  a  collision  trajectory 
which  allows  two  aircraft  to'  fly  to  a  distance  of  less  than  1300  feet,  without  triggering  an  alarm  11  seconds 
before  the  collision. 

move_2500_to_1300_no_alarm_bef ore_ll_seconds  :  THEOREM 

3  (intruder, evader: state,  df :  [posnat— >  [-45 . . .45]]  ,  n:nat)  : 
collision_scenario(intruder , evader ,df ,n+ll/tstep)  A 
distance (indruder, evader)  =  2500  A 
distance (intruder_trajectory (intruder, df ,n) , 

evader_trajectory (evader ,n) )  <  1300  A 

V  (i : [0. . .n]  )  : 

-i  larcalert (evader.trajectory (evader, i) , 

intruder_traj  ectory (intruder , df , i) ) 

By  combining  these  theorems,  we  can  state  that  for  some  trajectories  an  alarm  will  sound  no  more  than 
11  seconds  before  collision  and  that  for  all  cases  an  alarm  will  sound  at  least  4  seconds  before  a  collision.  We 
believe  that  for  all  cases  the  greatest-lower  bound  time  when  the  alarm  will  sound  prior  to  a  collision  is  closer 
to  11  than  to  4.  In  order  to  reveal  that  bound,  we  need  to  find  strong  invariants  on  collision  trajectories. 
Notice,  for  example,  that  for  an  intruder  trajectory  s0  . . .  sn  and  an  evader  trajectory  t0  . . .  £n,  it  cannot  be 
the  case  that  they  lead  to  a  collision  incident  at  step  n  when  distance (,so,£n)  >  where 

R  —  collisionRange+intruderSpeedxnxtstep. 

Indeed,  any  intruder  aircraft  out  of  the  circle  of  center  (x(£n)  ,y  (£n) )  and  radius  R,  needs  a  larger  time 
than  nxtstep  to  reach  any  point  of  the  circle  of  center  (x(£n)  ,y(£n))  and  radio  collisionRange.  The 
property  above  can  be  expressed  in  PVS  as  follows. 

collision_invariant  :  LEMMA 

V  (intruder , evader : state ,  df :  [posnat-* [-45. . .45]]  ,  n:nat)  : 
collision_scenario (intruder , evader , df ,n) 

=> 

V  ( i :  [0 ... n] ) : 

distance (intruder_traj  ectory (intruder , df , i) , 
evader_traj ectory (evader ,n) )  < 
collisionRange+intruderSpeedx  (n-i)  xtstep 

The  proof  of  this  invariant  requires  the  following  lemmas. 

straight_line_f arthest :  LEMMA 

V  (intruder : state, df : [posnat— >[-45. . .45] ,n:nat)  : 

LET  straight_trajectory  »  A(n:posnat) : 0  IN 
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distance (intruder, 

intruder_tr a j  ect ory ( intruder , df , n) )  < 
distance (intruder , 

intruder.traj  ectory ( intruder , straight. tra j  ectory , n) ) 

absolute.distance :  LEMMA 

V  (intruder : st ate, n:nat)  : 
phi (intruder) =0 

LET  straight.traj ectory  =  A(n:posnat) :0  IN 
distance (intruder , 

intruder.traj  ect ory (intruder , straight.traj  ectory , n) ) 

=  intruderSpeedxnxtstep 

Lemma  straight  _line  Jar the  st  states  that  an  intruder  trajectory  following  a  straight  lines  reaches  a  point 
farthest  than  any  other  trajectory,  while  Lemma  absolute.distance  states  that  the  length  of  an  intruder 
trajectory  following  a  straight  line  is  the  same  as  intruderSpeedxnxtstep. 

We  intend  to  use  the  above  invariant  and  lemmas,  together  with  properties  derived  from  the  physical 
trajectories,  to  find  a  bound  greater  than  4  seconds  for  any  collision  scenario.  Under  particular  assumptions 
of  the  intruder  bank  angle  (given  by  the  function  df),  we  have  proven  that  there  exists  a  point  outside  of 
the  alerting  threshold  range  where  the  alarm  is  issued.  The  conjecture  is  expressed  in  PVS  as  follows 

bound  :  CONJECTURE 

V  (intruder , evader : state ,  df :  [posnat— >[-45. . .45]]  ,  n:nat)  : 
collision.scenario (intruder , evader , df , n) 

=* 

3(i :  [0.  .  .n]  )  : 

->  alerting_distance(evader_trajectory(evader,i) , 

intruder.traj ectory (intruder , df , i) )  A 
larcalert (evader.traj ectory (evader, i) , 

intruder.tra j ectory (intruder, df ,i) ) 

We  are  trying  to  generalize  the  proof  for  an  arbitrary  value  of  df .  If  the  attempt  is  successful,  it  gives  a  new 
greatest  lower  bound  of  5  seconds. 

6.  Conclusion.  Several  case  studies  have  been  performed  on  the  application  of  hybrid  automata  to 
the  modeling  of  systems  which  include  continuous  and  discrete  domains.  In  particular,  a  simplified  TCAS 
system  was  modeled  in  [9]  using  hybrid  automata.  That  work  focuses  on  establishing  a  hybrid  model  of  the 
closed  loop  system  formed  by  several  aircrafts  flying  under  TCAS  assumptions.  Although  it  is  claimed  that 
the  model  is  suitable  for  formal  analysis,  there  is  no  explicit  attempt  to  automate  the  proof  process.  On  the 
other  hand,  state  exploration  techniques  have  been  used  to  analyze  the  system  requirements  specification  of 
TCAS  II  written  in  RSML  [7];  we  refer  for  instance  to  [5,  2].  These  works  focus  on  the  reactive  aspect  of 
the  whole  system. 

In  the  work  presented  in  this  paper,  we  constructed  a  formal  model  of  the  kernel  of  an  alerting  algorithm 
and  we  studied  its  behavior  with  respect  to  a  model  of  collision  trajectories.  In  our  analysis,  we  assumed 
that  the  alerting  algorithm  runs  in  isolation  of  the  other  components  of  the  system.  We  defer  the  integration 
of  the  alerting  algorithm  with  rest  of  the  system,  for  example  TCAS,  for  future  research. 

An  abstract  model  of  the  algorithm  and  its  properties  were  developed  in  the  general  verification  system 
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PVS.  We  complemented  the  prover  capabilities  with  computer  algebra  tools.  Indeed,  differential  equations, 
resulting  from  physical  phenomena,  were  mechanically  verified  in  MuPAD.  Models  of  the  algorithm  and 
collision  trajectories  were  implemented  in  Java.  The  implementation  allowed  us  to  explore  collision  scenarios 
before  performing  rigorous  attempts  to  prove  properties. 

Although  we  have  confidence  in  the  conjectures  that  have  been  declared  as  axioms,  work  is  being  per¬ 
formed  [10]  in  the  development  of  a  PVS  library  on  transcendental  functions  which  complements  a  previous 
work  on  mathematical  analysis  in  PVS  [1].  Hence,  it  might  be  possible  in  the  near  future  to  replace  the 
axiomatic  definitions  with  theorems. 

Lower  and  upper  bounds  for  a  time  when  an  alarm  will  be  issued  before  a  collision  were  found.  Our 
immediate  goal,  in  the  verification  of  the  AILS  algorithm,  is  to  prove  certain  facts  about  the  characteristics 
of  the  aircraft  trajectories.  We  hope  that  these  facts  allow  us  to  prove  the  adequacy  of  the  alerting  algorithm 
for  a  time  large  enough  to  avoid  any  possible  collision  incident. 
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Appendix.  The  AILS  Alerting  Algorithm  in  PVS. 

X - 

X  AILS  Alerting  Algorithm  in  PVS 
f  Victor  Carreno  (v.a.carreno@larc.nasa.gov) 
l  Cesar  Munoz  (munoz@icase.edu) 

#/0  ICASE  -  NASA  Langley  Research  Center 

%  This  model  is  an  abstraction  of  the  algorithm  written  by 
X  Bill  Capron 

l  NASA  Langley  Research  Center 

X  and  described  by 

%  Mike  Jackson 

7*  Honeywell  Technology  Center 

X  Assumptions 

’/,  *  Coordinate  system: 

’/,  + — >x  — >  landing  direction 

X  I 

X  V 

’/.  y 

X  *  Two  dimensional 

X  *  Ground  speed  is  constant 

X - 


AILS  :  THEORY 

BEGIN 

7.—  Types 

Bank 

:  TYPE  = 

subrange (“45 , 45) 

deg_heading 

:  TYPE  = 

subrange (-180 , 180) 

State:  type  = 

[#  X 

:  real, 

y 

:  real, 

heading 

:  deg„heading, 
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phi 


:  Bank 


#] 

% —  Constants 


collisionRange 

:  real  = 

200 

alertTime 

:  real  = 

19 

alertRange 

:  real  = 

1000 

intruderSpeed 

:  real  = 

250 

evaderSpeed 

:  real  = 

250 

tstep 

:  real  = 

1/2 

divtstep(x :real)  :  real  = 

x*2 

maxStep 

:  real  = 

1  +  divtstep (alertTime) 

g 

:  real  = 

32+2/10 

-  Variables 

intruder , 

evader 

VAR  State 

df 

VAR  [posnat->Bank] 

phi 

VAR  Bank 

s,sl,s2 

VAR  State 

x , range 

VAR  real 

t  ,tl ,t2 

VAR  real 

n 

VAR  nat 

m 

VAR  posnat 

iarc 

VAR  subrange (0 , maxStep) 

arcrad,trkrate 

VAR  real 

idtrk  : 

VAR  posnat 

°/a —  Useful  functions 

pi  :  real  =  3141592/1000000 

cosd(x) :  real 
=  LET  r  =  x*pi/180  IN 

1  -  expt(r,2)/2  +  expt(r,4)/24  -  expt (r , 6) /720  +  expt (r ,8) /40320 

sind(x)  :  real 
=  LET  r  =  x*pi/180  IN 

r  -  expt(r,3)/6  +  expt (r , 5) /120  -  expt (r , 7) /5040  +  expt (r , 9) /362880 
tangent _well_def ined  :  AXIOM 
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FQRALL  (phi)  :  cosd(phi)  /=  0 


tand(phi):  real  - 
sind(phi) / cosd(phi) 

mod(n,m) :  RECURSIVE  nat  = 

IF  n  <  m  THEN  n 
ELSE  mod(n-m,m) 

ENDIF 

MEASURE  n 

sq(x) :  nonneg_real  =  x*x 

sqrt_well_def ined  :  AXIOM 
FORALL  (x:nonneg_real) : 

nonempty? ({z:nonneg_real  I  z*z  =  x}) 

sqrt (x :nonneg_real)  :  {z :nonneg_real  I  z*z  =  x} 

distance(sl , s2) :  real  = 

sqrt (sq(x(s2)~x(sl))  +  sq(y (s2)-y (si) ) ) 

collision(sl , s2) :  bool  = 
distance (si, s2)  <=  collisionRange 

alerting_distance(sl ,s2) :  bool  = 
distance (si , s2)  <=  alertRange 

trkrate(phi) :  real  = 

IF  phi  =  0  then  0 

ELSE  1845*tand (phi) /intruderSpeed 

ENDIF 

dx(intruder , evader ,t) :  real  = 

(x( intruder)  +  t*intruderSpeed*cosd (heading (intruder) ) ) 
(x (evader)  +  t*evaderSpeed) 

dy( intruder, evader ,t) :  real  = 

(y (intruder)  +  t*intruderSpeed*sind(heading(intruder) ) ) 
y (evader) 

dxdt (intruder) :  real  = 

intruderSpeed*cosd (heading (intruder) )  -  evaderSpeed 
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dydt (intruder) :  real  = 

intruder Speed* sind (heading (intruder ) ) 

R( intruder, evader ,t) :  real  = 

sqrt  (sq(dx( intruder , evader ,t) )  +  sq(dy (intruder , evader ,t))) 

tau (intruder , evader ,t) : real  = 

LET  div  =  sq(dxdt (intruder))  +  sq(dydt (intruder) )  IN 
IF  div  =  0  THEN  0 
ELSE 

- (dx (intruder , evader ,t)  *  dxdt (intruder)  + 
dy( intruder, evader, t)  *  dydt (intruder) ) /div 
ENDIF 

% —  Alerting  algorithm 

chkrange (range ,t) :  bool  = 

range  <=  alertRange  AND  t  <=  alertTime 

chktrack (intruder, evader ,t) :  bool  = 

LET  tau  =  tau (intruder, evader ,0)  IN 
IF  tau  <=  0  THEN  7. 

chkrange (R( intruder , evader  ,0)  ,t)  7. 

ELSIF  t+tau  >  alertTime  THEN  7. 

R  (  intruder ,  evader ,  alertTime)  7. 

<=  alertRange  7* 

ELSE  7, 

R  ( intruder ,  evader ,  tau)  7. 

<=  alertRange 
ENDIF 

ar c_loop( intruder , evader ,arcr ad, trkrate , idtrk, iarc) :  RECURSIVE  bool  = 
IF  iarc  =  maxStep  THEN  false 
ELSE 

LET  tpred  =  iarc*tstep  IN 

LET  xloc  =  x (evader)  +  evaderSpeed*tpred  IN 
LET  yloc  =  y (evader)  +  evaderSpeed*tpred  IN 
7,7o  There  are  two  cases  trkrate  >  0  or  trkrate  <  0 
LET  (xtrk,ytrk)  =' 

IF  trkrate  >  0  THEN 

(x( intruder)  +  arcrad* (sind (heading (intruder) +trkrate*tpred)  - 
sind (heading ( intruder) )) , 


tracks  are  diverging  (or  parallel) 
check  range  at  prediction  time  t 
tracks  are  converging 
closest  approach  beyond  alert  time 
check  range  at  alert  threshold 
closest  approach  within  alert  time, 
check  range  at  closest  approach. 
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y (intruder)  +  arcrad* (cosd(heading(intruder) ) - 

cosd (heading ( intruder) +trkrate*tpred) ) ) 

ELSE 

(x (intruder)  +  arcrad* (sind (heading (intruder) )  - 

sind (heading ( intruder) )+trkrate*tpred) , 
y (intruder)  +  arcrad* (cosd (heading (intruder) +trkrate*tpred)- 
cosd (heading ( intruder) ) ) ) 

END IF  IN 

IF  NOT  mod ( iar c , idtrk)  =  0  THEN  '/■  not  time  for  tangential  track 
LET  range  =  sqrt (sq(xtrk-xloc)  +  sq(ytrk-yloc) )  IN 
IF  chkrange (range, tpred)  THEN  true 

ELSE  arc_loop ( intruder , evader , arcrad , trkrate , idtrk , iarc+1) 

ENDIF 

ELSE  '/,  tangential  track 

LET  tantrk  =  heading (intruder)  +  tpred*trkrate  IN 

LET  int  =  intruder  WITH  [x:=xtrk,  y:=ytrk,  heading: =tantrk]  IN 

LET  eva  =  evader  WITH  [x:=xloc,  y:=yloc]  IN 

IF  chktrack (int , eva, tpred)  THEN  true 

ELSE  ar c_loop ( intruder , evader , arcrad , trkrate , idtrk , iarc+ 1) 

ENDIF 

ENDIF 

ENDIF 

MEASURE  (maxStep  -  iarc) 

larcalert (intruder , evader) :  bool  = 

LET  phi  =  phi (intruder)  IN 
LET  trkrate  =  trkrate (phi)  IN 
IF  trkrate  =  0  THEN 

chktrack ( intruder , evader , 0 ) 

ELSE 

LET  arcrad  =  sq(ihtruderSpeed) / (g*tand(phi) )  IN 
LET  idtrk  = 

IF  trkrate  >=  3  THEN  1 
ELSIF  trkrate  >=  1  +  1/2  THEN  2 
ELSIF  trkrate  >=  3/4  THEN  4 
ELSE  8 
ENDIF  IN 

ar c_loop ( intruder , evader , arcrad , trkrate , idtrk , 0) 

ENDIF 

% —  Model  of  trajectories 

next_intruder_state(s ,phi) :  State  - 
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LET  trk  =  heading (s)  +  tstep*trkrate (phi (s) )  IN 
s  WITH  [ 

x  :=  x(s)’  +  intruderSpeed*tstep*cosd(heading(s)) , 

y  :=  y(s)  +  intruderSpeed*tstep*sind(heading(s) ) , 

heading  :=  trk, 

phi  : =  phi 

] 

intruder_trajectory (s ,df ,n) :  RECURSIVE  State  = 

IF  n  =  0  THEN  s 
ELSE 

next_intruder_state(intruder_trajectory(s,  df,  n-1) ,df (n) ) 
ENDIF 
MEASURE  n 

evader_trajectory(s  ,n)  :  State  = 

(# 

x  :=  x(s)  +  evaderSpeed  *  tstep  *  n, 

y  :=  y(s), 

heading  :  =  heading(s) , 

phi  :=  phi(s) 

#) 

collision.scenario (intruder , evader ,df ,n) :  bool  = 
collision(intruder .trajectory (intruder ,df ,n) , 
evader _tr a j  ectory (evader , n) ) 


“/ —  Axioms 

sin_cos_sq_one  :  AXIOM 
FORALL  (x) : 

sq(sind(x))  +  sq(cosd(x))  =  1 

derivative_eq_zero_min  :  AXIOM 
FORALL  (intruder ,tl ,t2) : 

R ( intruder , evader , t 1+t au ( intruder , evader , t 1 ) )  <= 

R ( intruder , evader , t l+t2) 

asymptotic„decrease_zero_to_tau  :  AXIOM 
FORALL  (t,tl,t2:real)  : 

tau (intruder , evader ,t)  >=  0  AND  t2  <=  tau (intruder, evader ,t)  AND 

tl  <=  t2 

IMPLIES 
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R(intruder , evader ,t+tl)  >=  R(intruder , evader ,t+t2) 


asymptotic_increase_tau_to_zero  :  AXIOM 
FORALL  (t ,tl , t2 :real)  : 

tan (intruder, evader ,t)  <=  0  AND  tau(intruder, evader ,t)  <=  tl  AND 

tl  <=  t2 

IMPLIES 

R(intruder, evader, t+t2)  >=  R(intruder , evader ,t+tl) 

#/0 —  Theorems  and  Properties 

sqrt_of_sq:  theorem 

(sqrt (sq(x)))  =  abs<x) 

phi_not_0_tan_not_0  :  theorem 
NOT  phi  =  0  implies  not  tand(phi)  =  0 

alarm_at_alerting_distance  :  THEOREM 
FORALL  (evader , intruder)  : 

alert ing_distance (evader , intruder) 

IMPLIES 

larcalert (intruder , evader) 

move_2500_to_1300_no_alarm_bef ore_ll_seconds  :  THEOREM 
EXISTS  (intruder , evader ,df ,n)  ; 

collision_scenario (intruder , evader ,df ,n+divtstep(ll) )  AND 
distance (intruder, evader)  =  2500  AND 
distance (intruder.traj ectory (intruder ,df ,n) , 

evader_traj ectory (evader ,n))  <=  1300  AND 
FORALL  (i: subrange (0,n))  : 

NOT  larcalert ( intruder _tr a j ectory( intruder ,df , i) , 
evader_traj  ectory (evader , i) ) 

collision_invariant  :  LEMMA 

FORALL  (intruder , evader ,df ,n)  : 

collision_scenario (intruder , evader , df ,n) 

IMPLIES 

FORALL (i : subrange (0 ,n) ) : 

distance ( intruder_traj  ectory (intruder , df , i) , 
evader_traj ectory (evader ,n) )  <= 
collisionRange+intruderSpeed* (n-i) *tstep 

straight_line_f arthest :  LEMMA 
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FORALL  (intruder , evader ,df ,n)  : 

LET  straight  ..trajectory  =  LAMBDA  (n :  posnat)  :  0  IN 
distance (intruder, 

intruder^traj ectory (intruder ,df ,n))  <= 
distance ( intruder , 

intruder_tra j  ectory (intruder , straight_traj  ectory , n) ) 

absolute_distance :  LEMMA 
FORALL  ( intruder, n)  : 
phi ( intruder) =0 
IMPLIES 

LET  straight.traj ectory  =  LAMBDA (n: posnat) :0  IN 
distance (intruder , 

intruder_tra j  ectory (intruder , straight_traj  ectory , n) ) 

=  intruderSpeed*n*tstep 

bound  :  CONJECTURE 

FORALL  (intruder , evader ,df ,n)  : 

collision_scenario (intruder , evader , df ,n) 

IMPLIES 

EXISTS (i : subrange (0,n) )  : 

NOT  alert ing_distance (evader_traj ectory (evader ,i) , 

intruder _tr a j ectory ( intruder, df ,i))  AND 
larcalert (intruder_tr a j ectory (intruder ,df ,i) , 
evader_traj  ectory (evader , i) ) 


END  AILS 


